Plural security protocols have been put into service, in which two (or more) communicating parties involve either directly, in the protocol messaging, or in their setup a trusted third party that both parties have a trust relation with. The most prominent class of protocols resides in secure communication protocols like Secure Shell/Transport Layer Security (SSL/TLS), Datagram TLS (DTLS), Wireless TLS (WTLS), and Internet Protocol Secure (IPSec) when using digital certificates.
In those protocols, a Certificate Authority (CA) that signs the certificates, may be the trusted third party and the (self-signed) certificate of the CA may be used (trusted) by the communicating parties to verify the correctness of the certificates used in the protocol. Other examples, where such a setup is applied, is the Kerberos protocol or the UMA implementation of the OAuth2.o protocol.
FIG. 1 shows a principle underlying the prior art, and shows a network 100 comprising a Trusted Third Party (TTP) 1001 and at least two clients 1002.
Those protocols are considered, in which the knowledge and involvement of the TTP 1001 concerning the security protocol implies that the TTP 1001 issues information that the data (such as keys or credentials) used in the protocol is still to be trusted by the parties for its purpose.
FIG. 1 involves a Public Key Infrastructure (PKI), which means that the TTP 1001 (e.g. the CA) can provide information that the certificate(s) can still be trusted. In practice, this is often realized by using so-called Certificate Revocation Lists (CRL) on which revoked certificates are listed, or through an on-line protocol like Online Certificate Status Protocol (OCSP).
So, either the communicating parties 1002 may have copies of a CRL or can use OCSP (or both). Typically, the CA 1001 uses a server to run OCSP or to distribute CRLs.